Synchronous database replication with asynchronous transaction recovery

ABSTRACT

A disaster-recovery system contains a networked array of synchronous-to-asynchronous converter (SATC) modules that connect source databases to target backup databases. During backup, the system replicates each source-database transaction through a chain of these SATCs to a corresponding target, storing a local copy of the transaction on each SATC along the way. Each transaction&#39;s path between its source-target pair is identified by a set of tracking entries, where each entry identifies one SATC in the path. Every backup transfer between two SATCs in a chain is performed synchronously, such that a successor SATC confirms a successful transfer to a predecessor SATC only after the successor can confirm a successful transfer to the next SATC in the chain. During a subsequent recovery operation, tracking entries are regenerated to locate locally stored transactions that had not time to be fully replicated before a catastrophic failure had occurred.

BACKGROUND

The present invention relates to computer-data backup and recoverytechnology and in particular to improvements to disaster-recovery (DR)systems that allow such systems to more efficiently back up and recoverdata after a catastrophic data-loss event.

Disaster-recovery systems are today configured to back up and restoredata on a component, or server-to-server, basis. This is true even whenan entire data center is configured to be protected by a singledisaster-recovery system. Database transactions and other types ofinformation are captured from each information source, such as a sourcedatabase that logs database transactions into a local area of persistentstorage, and replicated to a target recovery database that is usuallylocated at a physically distinct site. Similarly, when recovering from acatastrophic loss, previously backed-up data is replicated from eachtarget database to a recovery database that will allow users to accessdata copied from the source.

Known DR systems may in practice require an enormous number ofcomponent-to-component connections, each of which captures or restoresdata associated with a single information source. In modern datacentersthat comprise thousands of databases and other types of informationrepositories, the complexity of such component-to-component DR systemsmakes them resource-intensive, difficult to configure, and burdensome tomanage.

In particular, because each source component may require independent,customized backup and recovery procedures, a network or systemadministrator has little control over a DR system's aggregate,datacenter-level resource utilization and task prioritization. Forexample, if a recovery operation requires 500 components to be restored,known DR systems must manage each restoration task independently, makingit difficult to prioritize or efficiently manage the consumption ofnetwork bandwidth and other resources required to recover lost data ofan entire datacenter.

In one example, a datacenter may comprise one thousand database serversthat are continuously backed up to target recovery servers scatteredacross three other sites. After a catastrophic failure that has affecteda subset of the database servers and a subset of the network connectionsbetween source-server/target-server pairs, recovery operations may behampered by the need to determine, one-by-one, which source databasesrequire access to recovery servers still at remote sites, which recoveryservers are still operational, and which recovery servers have theconnectivity required for recovery. These problems are furtheraggravated by the lack of a way to manage all recovery operations andall communications between source and recovery server pairs through adedicated connection.

Another problem with known DR systems is loss of database transactionsand other stored information that had been created or revisedimmediately before a catastrophic loss. Because a finite transfer timeis required to replicate a source transaction to a remote backup,transactions-in-transit that did not have time to reach a targetdatabase may be inaccessible during a recovery operation.

These technical flaws are rooted in the architecture of currentdisaster-recovery technology, which is inherently limited by topology toindependently backing up and restoring each data source individuallythrough a distinct communications line; and has no way to restore datathat was could not be stored successfully in a backup database fromwhich lost data can be recovered.

SUMMARY

An embodiment of the present invention is a disaster-recovery systemcomprising a processor, a memory coupled to the processor, and acomputer-readable hardware persistent-storage device coupled to theprocessor, the persistent-storage device containing program codeconfigured to be run by the processor via the memory to implement amethod for synchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion, the method comprising:

the processor detecting that a database transaction has been performedupon a source database and that the database transaction has been loggedto a local persistent-storage area of the source database;

the processor identifying a backup path, through a backup network, fromthe source database to a target database,

where the target database stores a backup copy of the source database,

where each non-database node on the backup path hosts a unique SATC(Synchronous-to-Asynchronous Converter) of a plurality of SATC modules,

where each SATC of the plurality of SATC modules comprises localpersistent storage dedicated to the each SATC,

where a contiguous segment of the backup path comprises a non-databaseprocessor node that connects a non-database predecessor node to anon-database successor node, and

where the plurality of SATC modules comprises a predecessor SATC hostedby the predecessor node, a processor SATC that comprises the processorand is hosted by the processor node, and a successor SATC hosted by thesuccessor node;

the processor receiving a copy of the detected transaction from thepredecessor SATC;

the processor storing the received transaction in the processor SATC'slocal persistent storage;

the processor forwarding the received transaction to the successor SATC;

the processor accepting from the successor SATC confirmation that thesuccessor SATC has stored the received transaction in the successorSATC's local persistent storage and has in turn accepted conformationfrom a next SATC along the backup path that the next SATC hassuccessfully received and stored the received transaction in the nextSATC's local persistent storage; and

the processor notifying the predecessor SATC that the receivedtransaction has been successfully stored both in the processor SATC'slocal persistent storage and in the successor SATC's local persistentstorage.

Another embodiment of the present invention is a method for synchronoussite-consolidated data backup with synchronous-to-asynchronous trafficconversion, the method comprising:

a processor of a disaster-recovery system detecting that a databasetransaction has been performed upon a source database and that thedatabase transaction has been logged to a local persistent-storage areaof the source database;

the processor identifying a backup path, through a backup network, fromthe source database to a target database,

where the target database stores a backup copy of the source database,

where each non-database node on the backup path hosts a unique SATC(Synchronous-to-Asynchronous Converter) of a plurality of SATC modules,

where each SATC of the plurality of SATC modules comprises localpersistent storage dedicated to the each SATC,

where a contiguous segment of the backup path comprises a non-databaseprocessor node that connects a non-database predecessor node to anon-database successor node, and

where the plurality of SATC modules comprises a predecessor SATC hostedby the predecessor node, a processor SATC that comprises the processorand is hosted by the processor node, and a successor SATC hosted by thesuccessor node;

the processor receiving a copy of the detected transaction from thepredecessor SATC;

the processor storing the received transaction in the processor SATC'slocal persistent storage;

the processor forwarding the received transaction to the successor SATC;

the processor accepting from the successor SATC confirmation that thesuccessor SATC has stored the received transaction in the successorSATC's local persistent storage and has in turn accepted conformationfrom a next SATC along the backup path that the next SATC hassuccessfully received and stored the received transaction in the nextSATC's local persistent storage; and

the processor notifying the predecessor SATC that the receivedtransaction has been successfully stored both in the processor SATC'slocal persistent storage and in the successor SATC's local persistentstorage.

Yet another embodiment of the present invention is a computer programproduct, comprising a computer-readable hardware storage device having acomputer-readable program code stored therein, the program codeconfigured to be executed by a disaster-recovery comprising a processor,a memory coupled to the processor, and a computer-readable hardwarestorage device coupled to the processor, the storage device containingprogram code configured to be run by the processor via the memory toimplement a method for synchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion, the method comprising:

the processor detecting that a database transaction has been performedupon a source database and that the database transaction has been loggedto a local persistent-storage area of the source database;

the processor identifying a backup path, through a backup network, fromthe source database to a target database,

where the target database stores a backup copy of the source database,

where each non-database node on the backup path hosts a unique SATC(Synchronous-to-Asynchronous Converter) of a plurality of SATC modules,

where each SATC of the plurality of SATC modules comprises localpersistent storage dedicated to the each SATC,

where a contiguous segment of the backup path comprises a non-databaseprocessor node that connects a non-database predecessor node to anon-database successor node, and

where the plurality of SATC modules comprises a predecessor SATC hostedby the predecessor node, a processor SATC that comprises the processorand is hosted by the processor node, and a successor SATC hosted by thesuccessor node;

the processor receiving a copy of the detected transaction from thepredecessor SATC;

the processor storing the received transaction in the processor SATC'slocal persistent storage;

the processor forwarding the received transaction to the successor SATC;

the processor accepting from the successor SATC confirmation that thesuccessor SATC has stored the received transaction in the successorSATC's local persistent storage and has in turn accepted conformationfrom a next SATC along the backup path that the next SATC hassuccessfully received and stored the received transaction in the nextSATC's local persistent storage; and

the processor notifying the predecessor SATC that the receivedtransaction has been successfully stored both in the processor SATC'slocal persistent storage and in the successor SATC's local persistentstorage.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the structure of a computer system and computer programcode that may be used to implement a method for synchronoussite-consolidated data backup with synchronous-to-asynchronous trafficconversion in accordance with embodiments of the present invention.

FIG. 2 shows a generalized overview of an architecture of a conventionaldisaster-recovery system.

FIG. 3A shows a two-site detail of the disaster-recovery architecture ofFIG. 2,

FIG. 3B shows an improved disaster-recovery system comprising anapplication of the present invention to the two-site architecture ofFIG. 3A.

FIG. 4 illustrates an application of FIG. 3B's improveddisaster-recovery system to the enterprise of FIG. 2.

FIG. 5 shows details of an architecture of a synchronous-to-asynchronousinterface of an improved disaster-recovery network, in accordance withembodiments of the present invention.

FIG. 6 is a flow chart that shows steps of a method for processingincoming transactions by a synchronous-to-asynchronous converter, inaccordance with embodiments of the present invention.

FIG. 7 is a flow chart that shows steps by which a content-managermodule of a synchronous-to-asynchronous converter creates and storessets of tracking entries, in accordance with embodiments of the presentinvention.

FIG. 8 is a flow chart that shows steps by which a log-sender module ofa synchronous-to-asynchronous converter forwards received databasetransactions to successor systems during a backup operation, inaccordance with embodiments of the present invention.

FIG. 9 is a flow chart that shows steps performed by a backup targetdatabase in order to initiate recovery of lost transactions that had notbeen fully backed up at the time of a catastrophic data-loss event, inaccordance with embodiments of the present invention.

FIG. 10 is a flow chart that shows steps performed, during apriority-process procedure, by an SATC located along a path between asource database and a target database, in accordance with embodiments ofthe present invention.

DETAILED DESCRIPTION

Modern-day disaster-recovery systems comprise policies, software tools,and procedures that enable a business to resume normal operation asquickly as possible after a catastrophic data loss. These systemsautomatically backup and restore lost IT resources required by thebusiness, such as data stored in databases or other repositories,transactional records, application-configuration data, system software,error logs, and other software entities.

Known disaster-recovery systems generally operate by capturing suchelements of production data as each element is created and stored on asource data repository. Captured data is copied to “target” backupsystems at one or more remote recovery sites. Such disaster-recoverysystems may continuously capture and copy production data as each dataelement is created, or may periodically copy aggregated collections ofproduction data according to a backup schedule.

When a disaster renders data stored on some or all of the productionservers inaccessible or unreliable, the disaster-recovery systemresponds by restoring the backup copies from the target systems toknown-good servers or other information repositories from which thebacked-up data may be accessed by users.

Disaster-recovery systems generally require a distinct backup orrecovery process for each source repository. For example, if a site of adistributed enterprise network comprises 200 databases, a sitewidedisaster-recovery system may comprise 200 dedicated software proceduresthat each monitor and backup one of those databases. This is a technicalproblem that exists in current disaster-recovery technology that mayrequire an enterprise's network infrastructure to support hundreds oreven thousands of distinct datastreams and network connections.

Furthermore, known disaster-recovery systems generally cannot recoverthe final database transactions that occurred shortly before acatastrophic data loss if those final transactions did not have time toreplicate through a network all the way from a source database (thedatabase being protected by the DR system) to a target backup database.

Embodiments of the present invention provide a technical improvement toexisting disaster-recovery technology because they comprise methods andsystems that improve the efficiency, speed, and accuracy of backup andrecovery procedures by consolidating an entire site's disaster-recoverytraffic into a single data stream.

The present invention further improves the current state-of-the-art ofdisaster recovery technology by inserting novel“synchronous-to-asynchronous converters” (or “SATC” units) along pathsthroughout the back-end inter-site network infrastructure. These SATCstransfer data between source and target servers throughdisaster-recovery pathways called “disaster-recovery pipes” (“DR pipes”)that use improved “synchronous” backup and recovery procedures that aremore robust than current “asynchronous” methods.

Each source database that is protected by a DR system and eachcorresponding target database that stores the DR system's backup of thesource database may be connected by one or more distinct sequences ofSATCs along one or more paths of the DR network. When a transaction isperformed on the source database, the source database engine logs thetransaction in the source database's persistent storage area andforwards the transaction through the network path. The transaction ispropagated along the path, through each SATC in the sequence, to thetarget database. When an SATC in the sequence receives the transaction,that SATC stores the transaction in the SATC's local persistent storage,forwards the transaction to its successor SATC along the path, andreturns confirmation to the SATC's predecessor in the path when the SATCreceives confirmation that the successor has successfully stored theforwarded transaction.

The terms synchronous replication and asynchronous replication are usedhere to identify methods of confirming the successful receipt andstorage of a transaction or other type of data communication by adatabase or SATC along the network path.

An asynchronous data transfer from a first predecessor system to a firstsuccessor system (such as a predecessor SATC 5100 and a successor SATC5000 of FIG. 5, a source database 5100 and a successor SATC 5000, or apredecessor SATC 5000 and a target database or successor SATC 5200) isconsidered to be completed when the first successor confirms to thefirst predecessor that the first successor has successfully received andstored the transferred data in the first successor's local persistentstorage 509.

However, a synchronous data transfer from a first predecessor system toa first successor (such as a first predecessor 5100 and a firstsuccessor SATC 5000 in FIG. 5) is not considered to be completed untilthe first successor confirms to the first predecessor that the firstsuccessor has:

i) received and stored the transferred data in the first successor'slocal persistent storage 509;

ii) forwarded the transferred data to a second successor system (such asa successor 5200 in FIG. 5); and

iii) has received confirmation from the second successor 5200 that thesecond successor 5200 has stored the transferred data in the successor5200's local persistent storage 529.

In other words, when data is replicated asynchronously through adaisy-chain of SATCs or other systems, each transfer between a pair ofadjacent systems is considered to be completed when the receiving systemconfirms to the sending system that the receiving system hassuccessfully received and stored the transferred data. But when data isreplicated synchronously, a two-system transfer is considered completedonly when the receiving system confirms to the sending system that thetransferred data has been successfully received and stored both in thereceiving system's persistent storage and in the persistent storage ofone or more downstream systems in the daisy-chain.

Known disaster-recovery systems support only asynchronous replicationprocedures, which, although less robust, may be faster and easier toimplement than synchronous replication. The present invention comprisessynchronous-to-asynchronous converters 5000 that translate source datastreams, which originate by means of asynchronous transfers from asource database, into a sequence of synchronous SATC-to-SATC datatransfers; and then asynchronously store the transferred data in atarget database. As will be described in the following figures, thesesynchronous replication procedures provide greater robustness andaccuracy during a recovery procedure, and reduce the likelihood that theDR system will be unable to recover database transactions that had beenlogged just before the occurrence of a catastrophic event.

During a recovery operation, synchronous communications enable acompliant improved disaster-recovery system to locate transactions of asource database that have not yet had time to reach a target database,or had been lost en route to a target database when a catastrophicfailure occurred. As described in FIGS. 9 and 10, embodiments of thepresent invention improve upon current DR systems by implementing areverse synchronous procedure called a “priority procedure,” whichsynchronously traces lost transactions through a network path in reversedirection from a target database to the transactions' original sourcedatabases. Such a priority procedure allows the DR system to findotherwise-lost transactions that had been stored in SATCs along thenetwork path, even if those stored transactions never reached the backuptarget database.

These improvements also allow network-management systems to more easilymeasure a disaster-recovery system's performance characteristics andresource consumption. Instead of forcing a network to manage largenumbers of constantly varying data streams, embodiments of the presentinvention allow a network-management system, such as a cloud-managementplatform, to handle an entire site's disaster-recovery traffic as asingle consolidated stream. These improvements also allow adisaster-recovery system to quickly locate and recover databasetransactions that would otherwise have been lost during the catastrophicdata-loss event. Finally, these improvements mitigate burdens imposed byknown DR technology on network-management platforms, allowingnetwork-management applications to more easily perform tasks likemeasuring resource consumption and latency, determining when and how tothrottle bandwidth, dynamically rerouting traffic, and implementingencryption procedures.

None of these improvements are incorporated in known disaster-recoveryapplications and technology and are not well-understood, conventional,or routine within the field of disaster-recovery technology.

The present invention may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

FIG. 1 shows a structure of a computer system and computer program codethat may be used to implement a method for synchronous site-consolidateddata backup with synchronous-to-asynchronous traffic conversion inaccordance with embodiments of the present invention. FIG. 1 refers toobjects 101-115.

In FIG. 1, computer system 101 comprises a processor 103 coupled throughone or more I/O Interfaces 109 to one or more hardware data storagedevices 111 and one or more I/O devices 113 and 115.

Hardware data storage devices 111 may include, but are not limited to,magnetic tape drives, fixed or removable hard disks, optical discs,storage-equipped mobile devices, and solid-state random-access orread-only storage devices. I/O devices may comprise, but are not limitedto: input devices 113, such as keyboards, scanners, handheldtelecommunications devices, touch-sensitive displays, tablets, biometricreaders, joysticks, trackballs, or computer mice; and output devices115, which may comprise, but are not limited to printers, plotters,tablets, mobile telephones, displays, or sound-producing devices. Datastorage devices 111, input devices 113, and output devices 115 may belocated either locally or at remote sites from which they are connectedto I/O Interface 109 through a network interface.

Processor 103 may also be connected to one or more memory devices 105,which may include, but are not limited to, Dynamic RAM (DRAM), StaticRAM (SRAM), Programmable Read-Only Memory (PROM), Field-ProgrammableGate Arrays (FPGA), Secure Digital memory cards, SIM cards, or othertypes of memory devices.

At least one memory device 105 contains stored computer program code107, which is a computer program that comprises computer-executableinstructions. The stored computer program code includes a program thatimplements a method for synchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion in accordance withembodiments of the present invention, and may implement otherembodiments described in this specification, including the methodsillustrated in FIGS. 1-10. The data storage devices 111 may store thecomputer program code 107. Computer program code 107 stored in thestorage devices 111 is configured to be executed by processor 103 viathe memory devices 105. Processor 103 executes the stored computerprogram code 107.

In some embodiments, rather than being stored and accessed from a harddrive, optical disc or other writeable, rewriteable, or removablehardware data-storage device 111, stored computer program code 107 maybe stored on a static, nonremovable, read-only storage medium such as aRead-Only Memory (ROM) device 105, or may be accessed by processor 103directly from such a static, nonremovable, read-only medium 105.Similarly, in some embodiments, stored computer program code 107 may bestored as computer-readable firmware 105, or may be accessed byprocessor 103 directly from such firmware 105, rather than from a moredynamic or removable hardware data-storage device 111, such as a harddrive or optical disc.

Thus the present invention discloses a process for supporting computerinfrastructure, integrating, hosting, maintaining, and deployingcomputer-readable code into the computer system 101, wherein the code incombination with the computer system 101 is capable of performing amethod for synchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion.

Any of the components of the present invention could be created,integrated, hosted, maintained, deployed, managed, serviced, supported,etc. by a service provider who offers to facilitate a method forsynchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion. Thus the presentinvention discloses a process for deploying or integrating computinginfrastructure, comprising integrating computer-readable code into thecomputer system 101, wherein the code in combination with the computersystem 101 is capable of performing a method for synchronoussite-consolidated data backup with synchronous-to-asynchronous trafficconversion.

One or more data storage units 111 (or one or more additional memorydevices not shown in FIG. 1) may be used as a computer-readable hardwarestorage device having a computer-readable program embodied thereinand/or having other data stored therein, wherein the computer-readableprogram comprises stored computer program code 107. Generally, acomputer program product (or, alternatively, an article of manufacture)of computer system 101 may comprise the computer-readable hardwarestorage device.

In embodiments that comprise components of a networked computinginfrastructure, a cloud-computing environment, a client-serverarchitecture, or other types of distributed platforms, functionality ofthe present invention may be implemented solely on a client or userdevice, may be implemented solely on a remote server or as a service ofa cloud-computing platform, or may be split between local and remotecomponents.

While it is understood that program code 107 for a method forsynchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion may be deployed bymanually loading the program code 107 directly into client, server, andproxy computers (not shown) by loading the program code 107 into acomputer-readable storage medium (e.g., computer data storage device111), program code 107 may also be automatically or semi-automaticallydeployed into computer system 101 by sending program code 107 to acentral server (e.g., computer system 101) or to a group of centralservers. Program code 107 may then be downloaded into client computers(not shown) that will execute program code 107.

Alternatively, program code 107 may be sent directly to the clientcomputer via e-mail. Program code 107 may then either be detached to adirectory on the client computer or loaded into a directory on theclient computer by an e-mail option that selects a program that detachesprogram code 107 into the directory.

Another alternative is to send program code 107 directly to a directoryon the client computer hard drive. If proxy servers are configured, theprocess selects the proxy server code, determines on which computers toplace the proxy servers' code, transmits the proxy server code, and theninstalls the proxy server code on the proxy computer. Program code 107is then transmitted to the proxy server and stored on the proxy server.

In one embodiment, program code 107 for a method for synchronoussite-consolidated data backup with synchronous-to-asynchronous trafficconversion is integrated into a client, server and network environmentby providing for program code 107 to coexist with software applications(not shown), operating systems (not shown) and network operating systemssoftware (not shown) and then installing program code 107 on the clientsand servers in the environment where program code 107 will function.

The first step of the aforementioned integration of code included inprogram code 107 is to identify any software on the clients and servers,including the network operating system (not shown), where program code107 will be deployed that are required by program code 107 or that workin conjunction with program code 107. This identified software includesthe network operating system, where the network operating systemcomprises software that enhances a basic operating system by addingnetworking features. Next, the software applications and version numbersare identified and compared to a list of software applications andcorrect version numbers that have been tested to work with program code107. A software application that is missing or that does not match acorrect version number is upgraded to the correct version.

A program instruction that passes parameters from program code 107 to asoftware application is checked to ensure that the instruction'sparameter list matches a parameter list required by the program code107. Conversely, a parameter passed by the software application toprogram code 107 is checked to ensure that the parameter matches aparameter required by program code 107. The client and server operatingsystems, including the network operating systems, are identified andcompared to a list of operating systems, version numbers, and networksoftware programs that have been tested to work with program code 107.An operating system, version number, or network software program thatdoes not match an entry of the list of tested operating systems andversion numbers is upgraded to the listed level on the client computersand upgraded to the listed level on the server computers.

After ensuring that the software, where program code 107 is to bedeployed, is at a correct version level that has been tested to workwith program code 107, the integration is completed by installingprogram code 107 on the clients and servers.

Embodiments of the present invention may be implemented as a methodperformed by a processor of a computer system, as a computer programproduct, as a computer system, or as a processor-performed process orservice for supporting computer infrastructure.

FIG. 2 shows a generalized overview of an architecture of a conventionaldisaster-recovery system. The example of FIG. 2 comprises six instancesof data-center sites 200, but this example should not be construed tolimit embodiments to DR implementations that comprise six sites.

Known disaster-recovery (DR) technology operates by establishing acomponent-specific link between each production database, server, orother information repository of source data, and one or more “target”servers to which the production data is backed up by a DR system.

FIG. 2 represents such architectures in a general, non-rigorous mannerby showing subsets of the many links between each site 200 of anenterprise network's production sites and its disaster-recovery sites.Each connection represents a network link between a source repository ata production site and a target backup server at a disaster-recoverysite.

Although some DR implementations may not mix source and target serversat a same site 200, the generalized example of FIG. 2 shows a case inwhich each data center hosts both source and target informationrepositories. In this figure, however, no target database is used toback up a source database at the same site. Although not an essentialelement of DR systems described in this document, most implementationsstore recovery data at a site that is physically distinct from the siteof the source data.

FIG. 2 is intended to graphically represent the fact thatdisaster-recovery systems require many distinct connections betweendata-center sites. This complexity makes it difficult or impossible tomanage disaster-recovery traffic at a data-center level, rather than ata server level, forcing network-management systems to assume the bruntof traffic management using only poorly suited network-management tools.The need for large numbers of independent data streams also prevents anetwork-management platform or cloud-management facility from easilymonitoring a disaster-recovery system's quality-of-servicecharacteristics, such as latency, or the system's trafficcharacteristics, such as an amount of bandwidth required by eachconnection or a total aggregate bandwidth used by an entire site 200.

FIG. 3A shows a two-site detail of the disaster-recovery architecture ofFIG. 2. FIG. 3A shows connections between two instances of element 200.

The two data-center sites 200 in FIG. 3A are similar in form andfunction to the data centers 200 of FIG. 2, which each contain multipledata repositories. In FIG. 3A, a distinct network link connects eachsource component of one of the two sites 200 to a corresponding targetcomponent of the other site 200. A DR system would use each link to copydata between one of the corresponding component pairs. For example, if asource component at one site hosts a “source” production database and atarget component at the other site hosts a “target” backup database, thedisaster-recovery system requires a distinct network connection in orderto transfer copies of each data element or database transaction loggedinto the source database's local persistent storage to persistentstorage of the backup database.

Known DR systems suffer from weaknesses that arise from thiscomponent-to-component link architecture, which can result in adisaster-recovery system requiring a large number of distinct,independently managed data paths. In more complex implementations, wherea single data site's components are backed up to more than one backupsite, a disaster-recovery topology can be even more complicated. Thiscomplexity prevents the creation of a single point of control formanaging an entire site, making network-management and disaster-recoverymanagement tasks cumbersome or impossible.

FIG. 3B shows an improved disaster-recovery system comprising anapplication of the present invention to the two-site architecture ofFIG. 3A. FIG. 3B identifies elements 200 a, 200 b, and 300-310.

Items 200 a and 200 b represent the same type of data-center sites 200shown in FIGS. 2 and 3A. Sites 200 a and 200 b are also each associatedwith the same plethora of data connections described in the earlierfigures.

Here, however, the plurality of disaster-recovery component-specificdata streams of source production site 200 a are consolidated by a firstbank of synchronous-to-asynchronous converter (SATC) modules 300 a intoa single stream. The consolidated stream is then transmitted by thefirst SATCs 300 a through a disaster-recovery (DR) network composed of anetwork of DR pipes 310 to a second bank of SATCs 300 b, which restorethe consolidated stream back to a set of component streams. Each DR pipe310 may be implemented as one or more network segments or high-speedcommunications links, as is known in the art. Each stream then deliversbackup data to a distinct backup database at one or more target backupsites 200 b.

FIG. 3B thus illustrates in a general manner one advantage of thepresent invention. By consolidating a large number of distinct networkconnections into a consolidated data stream that may be transferredthrough a network path of DR pipes, the present invention's improved DRtechnology provides a single point of control from which an entire datacenter's disaster-recovery traffic may be monitored, measured,encrypted, routed, or otherwise tracked or managed by anetwork-management platform or by the disaster-recovery system itself.

FIG. 4 illustrates an application of FIG. 3B's improveddisaster-recovery system to an enterprise similar to that of FIG. 2.FIG. 4 shows elements identified by reference numbers 200 and 300-310.

Data-center sites 200 are similar in form and function to sites 200 ofFIG. 2, SATC banks 300 are identical in form and function to the SATCbanks 300 a and 300 b of FIG. 3B, and DR pipe 310 is identical in formand function to DR pipes 310 of FIG. 3B.

As in FIG. 3B, each bank 300 of SATC modules consolidatesdatabase-backup data streams originating from source databases of a site200 into a single consolidated stream and forwards the consolidatedstream across a DR network comprised of DR pipes 310.

In a more general case, a single SATC bank 310 may consolidate datastreams associated with more than one site 200, or a single site 200 maydata generate streams that are consolidated by more than one SATC bank310. Such embodiments are not included in the examples shown in thefigures, but are within the scope of the present invention.

The consolidated data streams travel along network paths between sourceand target databases located at various sites 200. Each network path mayconsist of an arbitrary number of SATC modules connected by DR pipes 310and, as a data item traverses a network path, each SATC along the waystores a copy of the data item in the SATC's local persistent-storagearea; In this way, transactions and data items originating from a sourcedatabase at a first datacenter site 200 are replicated and stored ateach step along a network path to a target database at a seconddatacenter site 200.

Other embodiments may comprise variations of this architecture, but inall cases, a plurality of component data streams originating at a firstsource site 200 are consolidated by one or more banks 300 of SATCs intoone or more aggregated (possibly site-specific) data streams that aretransferred through the high-speed DR pipes 310 to a sequence of otherSATCs. When the data stream reaches its target-database destination, thelast SATC along the path reverses any aggregation, unpacking theconsolidated data stream into component data streams that deliver theoriginal data to appropriate backup systems at a target site 200.

Data replication between SATC modules along a DR network path areperformed in a synchronous manner, where the term “synchronous” is giventhe narrow meaning defined above and in FIGS. 5 and 6. Here, asynchronous replication stream requires a predecessor/successor pair ofSATCs to confirm a successful data transfer only when the successor inturn confirms that the successor has successfully transferred the datareceived from the predecessor to a third SATC further downstream.

When a disaster occurs, this data flow is reversed. Streams of backed-updata stored on a target database at a target site 200 may beconsolidated by one or more SATCs 300 into a consolidated data stream;the consolidated stream is transmitted along a recovery data paththrough DR pipes 310, ultimately reaching a final set of SATCs thatdecompose the consolidated stream into component data streams. Thesefinal data streams are then restored to a set of recovery servers thatprovide users access to the data that had become inaccessible on theoriginal source servers. In some embodiments, the recovery servers maynot be distinct from the original source servers when the source serversare capable of being returned to service.

These improved recovery procedures also include a “priority process”procedure that uses synchronous communications methods to locate andrecover database transactions and other data that had not been fullybacked up at the time that a catastrophic data-loss event had occurred.

This improved disaster-recovery technology provides benefits over knownDR systems, such as allowing a system platform to more easily monitorbandwidth and latency of an entire disaster-recovery system or of DRtraffic related to a specific data center or site by simply monitoring aconsolidated stream traveling through a DR pipe. This technology alsoprovides other benefits, such as an ability to route a specific site'sDR-related traffic through a particular path, to prioritize orbandwidth-limit DR traffic by site, and to recover source-databasetransactions would otherwise have been lost. Other benefits include animproved ability to allow disaster-recovery traffic to be encrypted on aper-site basis, even if individual components protected by the DR systemdo not themselves support encryption.

None of these innovations are currently in use in disaster-recoverysystems based on known technology, much less so widely in use that theymight be considered well-understood, routine, and conventional in thefield.

FIG. 5 shows details of an architecture of a synchronous-to-asynchronousinterface of an improved disaster-recovery network, in accordance withembodiments of the present invention. FIG. 5 shows elements identifiedby reference numbers 501-529, and 5000-5200. Item 5000 depicts detailsof the synchronous-to-asynchronous converter (SATC) modules identifiedby reference numbers 300, 300 a, and 300 b in FIGS. 3 and 4.

In order to better describe more generalized embodiments of the presentinvention, the remainder of this Specification will generally refer to“source,” “target,” “production,” or “backup” servers as “predecessor”and “successor” systems. Here, a predecessor is simply a database,server, computer system, SATC, or other networked entity that is asource for data transmitted to a successor database, server, computersystem, SATC, or other networked entity. In other words, predecessor andsuccessor terminology indicates an order in which a pair of entities arelocated along a data path, not the intrinsic nature or functionality ofthe entities themselves.

In FIG. 5, this terminology will be used to describe relationshipsbetween:

-   -   a predecessor entity 5100 that may be a source database, which        stores production data to be protected by the disaster-recovery        system, or a predecessor SATC;    -   a successor 5200 entity, which may be a target or backup        database that stores backup copies of a source database's        production data, or a successor SATC; and    -   a sequence of intermediary SATCs 5000, which transfer database        transactions and other data items passing between a source        database and a target database.

In embodiments and methods described in FIGS. 6-10, a disaster-recoverysystem of the present invention operating in normal data-capture andbackup mode comprises an SATC 5000 module capturing transactionsgenerated by and stored on a source database 5100 and then forwardingthose transactions synchronously through a sequence of other SATCs 5000configured along network paths of DR pipes 310 to one or more targetdatabases 5200. During a data-recovery operation, after the occurrenceof a catastrophic event, this data flow is reversed. The DR systemtransfers the previously stored data from the target database 5200through a sequence of SATCs 5000 along a network path of DR pipes 310 toa recovery system accessible by users. In some embodiments, the recoverysystem may be the original source system, but in other embodiments, therecovery system and the source system are distinct.

In either case, each SATC 5000 receives data from a predecessor entity5100, stores the received data in the SATC's local persistent storagearea 509, and forwards the received data to a successor entity 5200.Depending on the SATC's location in the DR network topology and on theoperation being performed, these predecessor and successor entities maybe a source database, a target database, or another SATC module.

Referring in particular to FIG. 5, the three main modules shown in thefigure are: one or more synchronous-to-asynchronous converters (SATC)5000 that, during a backup operation, translate an incoming data stream,originating from a source database, into an outgoing data stream to bestored in a target database. As described above, and shown in FIG. 4,embodiments of the present invention may comprise complex networks ofSATCs 5000, which can provide multiple possible paths between varioussource and target databases. One or more SATC 5000 modules may belocated at each junction of DR pipes 310 comprised by the DR network.

During the DR system's normal backup mode, if predecessor 5100 is asource database, database engine 511 responds to a database-accessrequest by one or more local applications by performing a transactionupon the source database. Log writer component 513 then logs thetransaction on a persistent, non-transitory storage medium 515.

Unlike conventional DBMS implementations, log writer 513 also transmitsa copy of each transaction to a log receiver 505 component of SATC 5000,either through any communications infrastructure and method known in theart. Each SATC 5000 may be connected to a large number of predecessordatabases 5100 in this manner. In some embodiments, a particular bank ofSATCs 5000 may all be connected to databases 5100 at a particulardata-center site 200 or 200 a.

The SATC 5000's log receiver 505 stores received transactions in theSATC's own non-transitory persistent storage area 509. Log receiver 505also requests that a content manager module 503 create headerinformation for each received transaction. This information may includecharacteristics of a transaction, such as an identifier of thetransaction's originating database or system, an identifier of acharacteristic of a target database to which the transaction willultimately be persisted, or other information specifying transactioncharacteristics like a creation time, a size, or a priority.

A topology manager module 501 uses information accumulated by thecontent manager 503 to determine how the SATC 5000 should process eachtransaction received by the log receiver 505. This determination maycomprise enumerating a sequence of successor systems 5200 through whichthe transaction should be replicated in order for the transaction toreach the target database, as well as other data identifying the currentstatus of the transaction on each successor system. This operation isfacilitated by retrieval of certain types of information managed by thetopology manager 501, such as a list of source databases that containproduction data to be captured and backed up by the disaster-recoverysystem, a list of potential predecessor and successor systems connectedby DR pipes 310, a list of target databases capable of backing up datacaptured from the source database, and an overall topology of thedisaster-recovery system's network, including all possible network pathsbetween source and target sites 200, 200 a, and 200 b.

The log sender 507 module of SATC 5000 receives information from thecontent manager 503 that provides connectivity details for otherentities in the disaster-recovery system, including paths to thesuccessor database 5200. The log sender 507 then retrieves the storedtransaction from the SATC's persistent storage area 509 and uses thereceived connectivity information to route the transaction to thecorrect successor 5200.

Log writer 527 of the successor database 5200 receives the transactionfrom SATC 5000 and, under direction of database engine 525, stores thereceived transaction in the successor database 5200's persistent storage529. These steps are performed in a conventional manner, as is known inthe field of database-management systems, and in some embodiments, thepersistent storage 529 is a “target” database to which backed-up data isstored.

Like the SATC's topology manager 501, the successor system's topologymanager 521 stores descriptions of the topology of the disaster-recoverysystem and the entities that it monitors. This information is used bythe successor system 5200's recovery control component 523 during adata-recovery operation. During such a recovery, recovery control 523first retrieves all captured database transactions associated with abackup database on the persistent storage device 529 that are still intransit within SATC components 300, 300 a, or 300 b within the networkof DR pipes 310. Recovery control 523 then forwards those retrievedtransactions to the database engine 525 in order to ensure that thebackup database is fully current. The disaster-recovery system thenrestores the backup database to a new production server from which usersmay access the recovered data

These procedures are described in greater detail in FIGS. 6-10.

FIG. 6 is a flow chart that shows steps of a method for processingincoming transactions by a synchronous-to-asynchronous converter 5000,in accordance with embodiments of the present invention. FIG. 6 containssteps 600-670, which may be performed by embodiments that incorporatethe data structures of FIGS. 1-5.

In this figure, one or more source databases 5100 are connected througha network of SATC modules 5000 to one or more target databases 5200.During normal operation, a disaster-recovery system, in accordance withembodiments of the present invention, captures each transactionsubmitted to a source database 5100 and copies that transaction, throughthe network, to a corresponding target backup database 5200. Eachtransaction passes through a sequence of SATCs 5000 through the network,with each SATC 5000 receiving data from a predecessor SATC 5000 (or theoriginal source database 5100) and forwarding that data to a successorSATC 5000 (or the ultimate target database 5200).

During a recovery procedure, this procedure would be reversed. Datapreviously backed up to a target backup database is transferred througha sequence of SATCs 5000 to a source or recovery database that will makethe information available to users. Again, each SATC 5000 in thesequence forwards data from a set of predecessor systems to a set ofsuccessor systems. Predecessors of a particular SATC during a recoveryprocess may not be the same systems that operated as that SATC'spredecessors or successors during the original backup phase. Similarly,successors of a particular SATC during a recovery process may not be thesame systems that operated as that SATC's predecessors during theoriginal backup phase.

Prior to initiating a recovery, each SATC 5000 performs a novel“priority process” procedure that ensures that the backup database hasbeen updated with all transactions that were in transit at the time ofthe catastrophic event. This priority process comprises propagating arequest for any outstanding transactions in reverse order through allpredecessor systems along the path back to the source database. Therequesting SATC 5000 then waits for all predecessors to confirm thatevery transaction locally stored by one of the predecessors has beensuccessfully stored in the target database's persistent storage. Theseoperations are described in greater detail in FIGS. 9 and 10.

The steps described in FIGS. 6-8 overview steps taken by adisaster-recovery system, during the data-backup phase, by which an SATC5000 located along a network path between a source database and a targetdatabase transfers transactional records from the source database to thetarget database. In some embodiments, this SATC 5000 may be one of asequence of SATCs 5000 located along a path connecting the source andtarget database. As described above, each SATC 5000 along the path ispreceded by a first sequence of predecessor SATCs 5000 and followed by asecond sequence of successor SATCs 5000.

In step 600, an SATC 5000 receives from a predecessor system 5100 one ormore database transactions that have been recorded to persistent storage515 of the predecessor system 5100. These database transactions may haveoriginally been generated by users of a source database, which is beingmonitored and backed up by the disaster-recovery system, and then passedto the predecessor system 5100 through a sequence of other SATCs via thedisaster-recovery (DR) network 310. These transactions may be receivedby the SATC 5000's log receiver module 505 from a log writer module 513of the predecessor system 5100.

In step 610, log receiver 505 stores the received transaction ortransactions in the SATC 5000's persistent storage area 509.

In step 620, log receiver 505 notifies content manager 503 that thereceived transactions have been stored in the SATC's local persistentstorage 509. The log receiver also transmits to content manager 503 aunique transaction ID for each received transaction.

In step 630, content manager 503 retrieves from topology manager 501 alist of successor systems through which the received transactions mustbe passed in order to transmit the received transactions to theirultimate destination, a target backup database system. Topology manager501 is able to provide this information by maintaining a currentrepresentation of the disaster-recovery network topology.

The content manager 503 then generates a series of tracking entries foreach received transaction, where each tracking entry identifies one ofthe successor systems through which the received transaction must passin order to reach the target database. FIG. 7 describes these proceduresin greater detail.

In some embodiments, the tracking entries generated in this step mayeach identify only a direct successor system 5200 to which the SATC 5000can directly forward a transaction. In such embodiments, no trackingentries generated in this step identify successor systems that are notcapable of directly exchanging data with SATC 5000 with no interveningsystems.

In step 640, SATC 5000 determines whether the received transactions havebeen marked as requiring a synchronous replication mode. As mentionedabove, the terms synchronous replication and asynchronous replicationare used in this document in a specific, narrowly defined manner toidentify methods of confirming the successful receipt and storage oftransaction data through, or other type of data-replication task,through a chain of networked systems.

If the received transactions are marked as not requiring synchronousreplication, the method of FIG. 6 ends. If the received transactions areto be replicated synchronously, then the method of FIG. 6 continues withsteps 650-670.

In step 650, SATC 5000 determines whether any remaining transactions,not yet processed by SATC 5000, for the same source database willrequire synchronous replication. If no other synchronous replicationsare required, then SATC 5000 skips step 660 and continues with step 670.

In step 660, because other synchronous replication tasks remain, SATC5000 waits for all associated tracking entries for each remainingsynchronous transaction to be received and processed. As describedearlier, each tracking entry will identify a successor system throughwhich a remaining transaction will be propagated in order to store thattransaction in the target database. In this step, therefore, SATC 5000will wait for the arrival of tracking entries that each identify thesame source system, a transaction ID of an outstanding transactionoriginating from that source system, and a successor system throughwhich the transaction identified by the transaction ID must bereplicated in order to be transferred to the desired target system.

In step 670, SATC 5000 synchronously replicates any synchronouslyreceived transactions through the path of successor systems identifiedby the tracking entries. At the conclusion of this procedure, SATC 5000will receive confirmations that the received transactions have beensuccessfully replicated to the target database. Log receiver 505 willthen respond to predecessor system 5100 with confirmation that thetarget database's persistent storage has been successfully updated. Thisconfirmation will then be propagated by predecessor system 5100 throughthe predecessor portion of the system chain, back to the original sourcedatabase.

FIG. 7 is a flow chart that shows steps by which a content-managermodule 503 of a synchronous-to-asynchronous converter (SATC) 5000creates and stores sets of tracking entries, in accordance withembodiments of the present invention. FIG. 7 contains steps 700-750,which may be performed by embodiments that incorporate the datastructures of FIGS. 1-5.

Embodiments of the present invention generate and associate atransaction ID and a set of tracking entries for each transaction of thesource database that is captured, backed up to a target database, and,in the event of a recovery operation, restored to a new productiondatabase. These tracking entries allow embodiments to trace databasetransactions through sequences of SATCs 5000 when performing synchronousprocedures, such as a synchronous backup operation that copies atransaction from a source database, through a network of DR pipes andSATCs 5000, to a target database; a synchronous recovery operation thatcopies a previously backed-up transaction from a target database,through a network of DR pipes and SATCs 5000, to a recovery database; ora priority-process operation that traverses a network of DR pipes andSATCs 5000 in reverse order, from a target database back to a sourcedatabase, in order to locate lost copies of database transactions thatwere still in transit to a target database when a catastrophic eventoccurred.

Each such transaction is uniquely identified by a unique transaction IDand is accompanied by its transaction ID as the transaction is routedthrough a networked chain of SATCs 5000 from a source database to atarget database or from a target database to a recovery database.

The path through which a transaction is routed is identified by thattransaction's set of tracking entries. Each entry identifies one SATC5000 in the chain of SATCs 5000 that connect the transaction'soriginating database and destination database.

Each SATC 5000 contains a content manager module 503 that stores andmaintains tracking information about transactions that are captured,backed up, or restored by the disaster-recover (DR) system. The methodof FIG. 7 describes operations of content manager 503 performed in orderto create a new tracking entry when an SATC 5000 receives from apredecessor system 5100 one or more new database transactions that willneed to be backed up. This procedure elaborates upon step 630 of FIG. 6.

In step 700, content manager 503, having received a transaction ID foreach received, but as-yet unprocessed, transaction stored in the SATC'spersistent storage 509, requests from topology manager 501 a list of allSATC modules 5000 along each received transaction's path from thetransaction's source database to the transaction's destination database.

For each transaction, content manager 503 then uses these lists togenerate a set of tracking entries for each unprocessed transactionidentified by one of the received transaction IDs. Each tracking entryidentifies one of the SATC modules 5000 along the path associated with acorresponding transaction. At the conclusion of this step, contentmanager 503 will have generated a set or list of tracking entries foreach transaction stored in the persistent storage 509, where each set orlist identifies a sequence of SATCs 5000 that one of the transactionswould need to traverse in order to reach the transaction's destination.

In some embodiments, a method of FIG. 7 may be varied to perform steps710 and 720 prior to generating the sets or lists of tracking entries.Such embodiments may in certain implementations improve efficiency byeliminating the step of generating tracking entries that aresubsequently excluded, even if only temporarily, from furtherprocessing.

In step 710, content manager 503 optionally excludes certain of the setsof tracking entries from being processed by further steps of methods ofFIG. 7. This delays the replication of any transactions associated withthe excluded entries in order to prevent replication of certain logicalerrors that may have affected those transactions.

Such logical errors may occur when a transaction has not been stored inpersistent storage 509 for a duration of time longer than the nontrivialtransfer time necessary for that transaction to have reached storage 509from a source database. In such cases, content manager 503 in this stepexcludes further processing of generated tracking entries associatedwith that transaction until enough time has elapsed to ensure that thestored transaction is accurate and complete.

Other types of logical errors may occur if, for example, a particularsource database had been temporarily subject to errors. Transactionsreceived and stored in persistent storage 509 may thus be erroneousuntil the database has had sufficient time to correct the errors andtransfer corrected transactions to storage 509. If not enough time haselapsed since the resolution of the database problem to allowcorrections to be transferred to storage 509, content manager 503 willexclude tracking entries associated with the potentially erroneoustransactions in order to prevent those transactions from beingpropagated until corrected transactions can be transferred to storage509.

In step 720, content manager 503 further excludes other tracking entriesif those entries are found to already belong to previously generatedtracking-entry sets.

In step 730, content manager 503 groups the remaining tracking entriesinto new sets, where each set contains all tracking entries thatidentify a particular successor system 5100. For example, if an SATC5000 is connected through DR network pipes 310 to five other SATCs, eachof which is a potential successor system of SATC 5000, content manager503 may, in this step, sort the generated tracking entries into as manyas five sets. Here, each of the sets would consist of tracking entriesthat identify one of the potential successors. Because each trackingentry associates one transaction ID with one successor system, thetracking entries in any one of the new sets would identify allnon-excluded transactions stored in persistent storage 509 that are tobe transferred to one particular successor of the five successorsystems.

In step 740, each new set of tracking entries may be assigned one ormore quality-of-service (QoS) parameters. These parameters may, forexample, identify: an order in which the tracking entries in aparticular new set are to be processed; a network priority assigned toall entries in a particular new set; or other QoS parameters that may beassigned to network traffic.

The present invention is flexible enough to accommodate any method knownin the art, or preferred by an implementer, for selecting and assigningsuch QoS parameters to each new set or to each tracking entry in a newset.

In step 750, the content manager 503 returns the new sets of trackingentries to log receiver 505. Log receiver 505 then records the newlycreated tracking-entry sets into the SATC 5000's persistent storage 509.

FIG. 8 is a flow chart that shows steps by which a log-sender module 507of a synchronous-to-asynchronous converter 5000 forwards receiveddatabase transactions to successor systems 5200 during a backupoperation, in accordance with embodiments of the present invention. FIG.8 contains steps 800-890, which may be performed by embodiments thatincorporate the data structures of FIGS. 1-5, and that roughlycorrespond to steps of FIG. 6 that include step 660.

In step 800, the log sender 507 requests a listing of unprocessedtracking-entry sets from content manager 503. These listings hadpreviously been generated by content manager 503 through the method ofFIG. 7 and stored in the SATC's persistent storage 509 in step 750.

Step 810 begins an outer iterative procedure of steps 810-890 that isrepeated for each tracking-entry set received in response to the requestof step 800.

In step 820, log sender 507 receives from content manager 503 one of therequested tracking-entry sets. These sets may be received in an orderspecified by the QoS parameters associated with each set in step 740 ofFIG. 7. For example, if an implementer desires to process older setsfirst, content manager 503 will transmit sets in order of age.Similarly, if QoS parameters specify that the system should firstprocess sets that have higher network priority, higher-priority setswill be received first.

In step 830, log sender 507 requests from topology manager 501connectivity information for the particular successor system 5200associated with the received tracking-entry set currently beingprocessed.

Step 840 begins an inner nested iterative procedure of steps 840-890that is repeated once for each tracking entry comprised by thetracking-entry set being processed by the outer current iteration of theiterative procedure of steps 810-880.

In step 850, log sender 507 retrieves from the SATC 5000's persistentstorage 509 the transaction identified by the transaction ID of thecurrent tracking entry.

In step 860, log sender 507 transmits, through DR pipes 310 of thedisaster-recovery network, the transaction retrieved in step 850 to thesuccessor system 5200 identified by the current tracking-entry set.

In step 870, log sender 507 receives confirmation, through thedisaster-recovery network, from successor system 5200 that thetransaction transmitted in step 507 was successfully received and storedin successor system 5200's persistent storage 529.

In a synchronous replication procedure, the received confirmationfurther indicates that successor system 5200 itself has receivedconfirmation, from a downstream successor system to which successorsystem 5200 had replicated the transmitted transaction, that thetransmitted transaction has also been successfully received and storedin the persistent storage of the downstream successor system.

In step 880, log sender 507 directs content manager 503 to mark thecurrent tracking entry as having been processed. This will prevent thetracking entry from being included in a future tracking-entry set by afuture performance of a method of FIG. 7.

Step 890 is performed after the iterative procedure of step 840-880 hasprocessed every tracking entry of the current tracking-entry set.

In step 890, log sender 507 directs content manager 503 to mark theentire current tracking-entry set as having been processed.

FIG. 9 is a flow chart that shows steps performed by a backup “target”database in order to initiate recovery of lost transactions that had notbeen fully backed up at the time of a catastrophic data-loss event. FIG.9 contains steps 900-970, which may be performed by embodiments thatincorporate the data structures of FIGS. 1-5.

In step 900, database engine 525 of a target database 5200 initiates adisaster-recovery procedure in order to facilitate the recovery of datathat is no longer accessible from a source database due to theoccurrence of a catastrophic data-loss event. This initiating may beperformed in response to automatically detecting, through a network, amonitoring application, interactive user interface, or other automatedmeans known in the art, that the source database is no longer accessibleto users; or may be performed in response to extrinsic or manualdirection from an administrator, the disaster-recovery system, adatabase-management system, a network-management application, or someother automated application or platform.

In step 910, database engine 525, if possible, identifies thehighest-numbered or latest-in-time transaction ID (“max ID) thatrecovery control 523 will attempt to retrieve by means of a“priority-process” procedure in subsequent steps of FIG. 9. As explainedelsewhere in this document, a priority-process procedure usessynchronous replication methods to reproduce and traverse network pathsback to a source database, in order to locate and recover transactionsthat may not have had time to reach their target backup system at thetime of a catastrophic system failure. Here, the max ID identifies themost recently completed database transaction that could not becompletely backed up (that is, successfully stored in the target backupdatabase's persistent storage 529) before a catastrophic data-loss eventinterrupted the backup procedure.

The max ID may be determined by any means known in the art, such as byreceiving an identification from a source database from which thetransaction identified by the max ID originated, by receiving anidentification from a network-management platform or database-loggingapplication, or by means of manual identification by an administrator.In some embodiments, if it is not possible for database engine 525 toidentify the max ID, a max ID value may be determined empirically byfurther steps of FIG. 9.

In step 920, database engine 525 queries recovery control 523 for anidentification of the highest-numbered transaction ID of a transactionthat had been successfully backed up and stored in the target database'spersistent storage 529. This transaction ID will be the lower boundary(or “min ID”) of a range of transactions that recovery control 523 willattempt to retrieve by means of a priority-process procedure insubsequent steps of FIG. 9. In other words, the min ID identifies thelast database transaction that was successfully backed up and the max IDidentifies the last database transaction that was completed, but did nothave time to be backed up. Subsequent steps of the method of FIG. 9 willuse a priority process in an attempt to locate and recover losttransactions that fall within this range before the system's full-blown,site-wide data-recovery operation begins.

The max ID and the min ID initially identify upper and lower boundariesof a range of transactions that the disaster-recovery system will try toretrieve by means of the priority process before attempting to recoverydata stored in the target database 5200. This range of transactionscomprises transactions that had been executed on the original sourcedatabase, but may not yet have been fully replicated to the backuptarget database.

In step 930, recovery control 523 retrieves from target system 5200'stopology manager 501 an identification of a predecessor system that isthe direct predecessor of the target system 5200 along a network pathbetween the target database and a source database that is the originalsource of the transaction identified by the max ID.

In the example of FIG. 9, this predecessor is an SATC 5000, similar toSATC 5000 of FIG. 5, that is a direct predecessor of target database5200. Topology manager 521 is able to identify this direct predecessorbecause, like the SATC's topology manager 501, topology manager 521stores and maintains a representation of the topology of thedisaster-recovery network. This representation includes connectivitydata sufficient to identify or derive network paths from target database5200 to either the source database or to a recovery database to whichsource-database transactions previously backed-up to the targetdatabase's persistent storage 529 will be restored.

In step 940, recovery control module 523 directs predecessor system 5000to initiate a priority-process procedure for the range of transactionsbounded by the min ID and the max ID. If no max ID has been specified,recovery control module 523 directs predecessor system 5000 to initiatea priority-process procedure for all transactions with transaction IDsgreater than the min ID. These are transactions that were completed bythe source database but had not had time to be successfully replicatedto the target database.

The intent of this priority process is to ensure that the targetdatabase 5200 has received and stored all transactions that had not yetbeen fully replicated to the target backup database at the time of thesource-database's data loss. This helps ensure that the target databasehas been fully updated with all transactions that were in transit at thetime of the catastrophic event.

As explained in earlier figures, when a priority-process replication isrequested by an SATC 5000, the request is propagated through allpredecessor systems of the SATC 5000 along a reverse network path backto an original source database. The requesting SATC 5000 then waits foreach predecessor along that path to report whether the requestedtransaction has been stored in that predecessor's local persistentstorage and then successfully replicated to that predecessor's directsuccessor. The priority process concludes upon confirmation that therequested transaction has been replicated through the entire path, thusreaching the target database's persistent storage.

In step 950, SATC 5000, upon receiving the results of the priorityprocess, resets the value of the max ID to the highest-numberedtransaction ID of any transaction received by means of the priorityprocess. This means that the range of transactions that need to berecovered is adjusted to exclude transactions that have already beenrecovered by the priority process.

In step 960, the target database 5200 delays its recovery procedureuntil all transactions between the min ID and the max ID reach targetdatabase 5200 and stored in the target database 5200's persistentstorage 529.

In step 970, once all transactions have been stored in the target system5200's persistent storage 529, thus ensuring that the target databasehas been fully updated, the target database engine 525 begins itsfull-blown data-recovery operation, which will restore thesource-database backup, stored in the target database's storage 529, toa recovery database that will be accessible to users.

In one example of this procedure, target database engine 525 hadinitially identified the transaction identified by transaction ID #2450as being the highest-known ID (at this point, both the max ID and themin ID) of a transaction written to the source database before thecatastrophic data loss. This initial identification was made becausetransaction #2450 is the highest-numbered transaction stored in thepersistent storage 529 of the target database. Before initiating afull-blown recovery procedure that would recover transactions onlythrough transaction #2450, the target database launches apriority-process procedure that discovers that transactions #2451-2456had also been completed by the source database before the data-lossevent.

Here, the target database engine 525 had not been aware of the sixhigher-numbered transactions because those six transactions had not yetbeen replicated through the DR network all the way to the targetdatabase and stored in the target database's persistent storage 529. Thepriority process, however, discovered partially replicated records ofthose six transactions stored in the persistent storage of SATCs alongthe network path between the source and target databases.

In response to this discovery, the recovery control 529 determines thatthe highest-numbered transaction that had been performed upon the sourcedatabase was transaction #2456. Recovery control 529 then resets the maxID value to #2456, the highest-numbered ID of a transaction that hadbeen completed by the database prior to a catastrophic event. The targetdatabase 5200's database engine 525 is made aware that the targetdatabase will be an accurate backup of the source database only when alltransactions through transaction #2456 have been successfully receivedby the target database 5200 and stored in the target database'spersistent storage 529.

The target database then delays its full-blown disaster-recoveryprocedure until all database transactions within the min-ID/max-ID range(#2451-#2456) have had time to be replicated to the target database andstored in the target database's persistent storage area 529. Upon thereceipt and storage of all transactions through #2456, database engine525 initiates the disaster-recovery procedure in order to restore thefully updated contents of the target database to a recovery databasethat will be accessible to users.

FIG. 10 is a flow chart that shows steps performed, during apriority-process procedure, by an SATC 5000 located along a path betweena source database and a target database, in accordance with embodimentsof the present invention. FIG. 10 contains steps 1000-1065, which may beperformed by embodiments that incorporate the data structures of FIGS.1-5.

The method of FIG. 10 is performed by the SATC 5000 when a back-up“target” database, prior to initiating a recovery procedure for a lost“source” database, initiates a priority-process procedure in order toensure that the target database contains a fully updated, current copyof the source database. This priority-process request is propagatedthrough SATCs along a network path from the target database to thesource database, where the priority process identifies source-databasetransactions that had not yet been replicated along the entire path tothe target database at the time of data loss.

As shown in FIG. 5, SATC 5000 is one of the systems along the path,positioned between one or more sequentially configured predecessorsystems 5100 and one or more sequentially configured successor systems5200. During the original data-backup phase, transactions of the sourcedatabase are replicated through the path from predecessors 5100 throughSATC 5000 to successor 5200, and then to other downstream successorsystems, to finally reach the target database. During the priorityprocess, which is initiated (as described in FIG. 9) in order to updatethe target database prior to a database-recovery operation, thepriority-process request is forwarded in reverse order through the path,passing from successors 5200 through SATC 5000 to predecessor 5100, andthen to other predecessors leading to the original source databasesystem.

In step 1000, the content manager module 503 of SATC 5000, in responseto a priority-process request forwarded from a target database and toSATC 5000 by successor system 5200, identifies the SATC 5000's “min ID”transaction ID. This min ID identifies the most recent(highest-numbered) database transaction, received from the sourcedatabase via predecessor systems 5100, that had been received andsuccessfully stored in the local persistent storage 509 of the SATC 5000and then successfully forwarded to successor system 5200. Any completeddatabase transaction that has a transaction ID higher than the min IDwas not successfully received and stored in the target database, andthus must be recovered by the priority-process procedure before afull-blown database recovery operation can proceed.

In step 1005, the topology manager module 501 of SATC 5000 identifiespredecessor system 5100 and provides network topology and connectivityinformation that allows content manager 503 to locate and communicatewith predecessor system 5100.

In step 1010, SATC 5000's content manager 503 determines whether a maxtransaction ID (“max ID”) is known. The max ID is the highest-numberedtransaction that had been performed by the source database prior to thesource database's catastrophic failure. Before starting adisaster-recovery process, which will restore the source database fromits backup in the target database, the system will need to wait untilall “lost” source-database transactions, greater than the min ID and nogreater than the max ID, have had sufficient time to reach the targetdatabase.

As described in FIG. 9, the max ID may have been identified throughvarious means known in the art. In some embodiments, for example, themax ID may be supplied by successor system 5200 when successor system5200 forwards the priority-process request (initially generated by thetarget system) to SATC 5000. In other cases, the SATCs will continuouslyupdate the max ID value each time they locate another transaction thatis still replicating through the network.

If the max ID is not known, the max ID may in some cases be determinedempirically when the priority process is ultimately propagated to theSATC that is the first successor of the source database. Thehighest-numbered transaction to have been replicated to that firstsource-database successor will then be identified as having thehighest-numbered transaction ID that can possibly be recovered, and thishighest-numbered transaction will then be propagated along the networkpath, ultimately to the target database, as the true max ID value.

If the content manager 503 determines in step 1010 that the maxtransaction ID is already known, the method of FIG. 10 continues withsteps 1015-1030 before concluding with steps 1050-1065. If the finalvalue of the max transaction ID is not yet known, the SATC 5000 insteadperforms steps 1035-1050 before the method of FIG. 10 concludes withsteps 1050-1065.

In step 1015, having determined that a value of the max ID is known,content manager 503 determines whether all transactions associated withtransaction IDs within the min ID/max ID range have been successfullyprocessed by SATC 5000 and stored in SATC 5000's local persistentstorage 509. If so, the method of FIG. 10 concludes with steps1050-1065. If not, the method of FIG. 10 performs steps 1020-1030 beforeconcluding with steps 1050-1065.

In step 1020, having determined that a max ID is known (that is, that arange of incompletely replicated “to be processed” transactions isdefined) and that SATC 5000 has not yet processed all the transactionsin the range, content manager 503 determines whether the predecessorsystem 5100 is capable of implementing a priority process. If not, SATC5000 determines that at least one component of the disaster-recoverysystem network is not comprised by an embodiment of the presentinvention and the method of FIG. 10 ends with a fatal error in step1025.

If, however, content manager 503 determines that predecessor 5100 iscapable of implementing a priority process, the method of FIG. 10continues with steps 1030 and 1050-1065.

In step 1030, SATC 5000 directs predecessor 5100 to initiate a priorityprocess to recover transactions identified by IDs within the range ofthe previously identified min ID and max ID values. If predecessorsystem 5100 is an SATC, predecessor 5100 then pseudo-recursivelyperforms the method of FIG. 10.

In step 1035, the content manager 503, having determined in step 1010that the max transaction ID is not known, determines whether predecessorsystem 5100 is the original source database or is another SATC along thenetwork path between the source database and the target database. If thepredecessor is the source database, the method of FIG. 10 continues withstep 1040 before concluding with steps 1050-1065. If other SATCs arelocated on the path between the source database and predecessor 5100,the method of FIG. 10 continues with step 1045 before concluding withsteps 1050-1065.

In step 1040, having determined that predecessor 5100 is the originalsource database, content manager 503 identifies the true max ID value asbeing the highest-numbered transaction ID of a transaction that wassuccessfully stored in the source database's persistent storage 515. Ifthe source database is unavailable, due to problems related with thecatastrophic event, then content manager 503 identifies the true max IDvalue as being the highest-numbered transaction ID of a transaction thatwas successfully stored in the predecessor's database's persistentstorage 515.

In step 1045, having determined that predecessor 5100 is not theoriginal source database, content manager 503 directs predecessor SATC5100 to perform the previously requested priority process without a maxID. SATC 5000 assumes in this step that predecessor 5100 will continueto propagate the priority-process request backwards through the networkpath until the request finally reaches the source database (or the SATCthat is the direct successor to the source database, should the sourcedatabase be unreachable). The true max ID is then set to thehighest-numbered transaction ID of a transaction stored in the sourcedatabase's persistent storage 515 (or in the persistent storage 515 ofthe direct successor to the source database). That true max ID valuewill then be returned to SATC 5000, and will be propagated through eachSATC along the network path back to the target database.

In step 1050, SATC 5000 waits until any outstanding unprocessedtransactions within the range from min ID through max ID are received bySATC 5000 and stored in SATC 5000's persistent storage 509. Once thistask has completed, all transactions within the desired range will havebeen replicated along the path from the source ID to the target ID, asfar as the SATC 5000.

In step 1055, content manager 503 of SATC 5000 creates a set of trackingentries for each transaction within the min ID/max ID range received bySATC 5000 in step 1050. Each tracking-entry set identifies all successorSATCs along the remainder of path to the target system.

In step 1060, content manager 503 optionally sets a QoS priorityparameter for each tracking-entry set generated to 1055. This priorityparameter will assign each tracking entry the highest priority on thesuccessor system 5200 to which the associated transaction will bereplicated. Each tracking-entry set will ultimately be forwarded, alongwith the set's associated priority parameter, to the next successorsystem identified by that tracking-entry set, and this process willcontinue until all transactions within the min ID/max ID range have beensuccessfully replicated to and stored on the target database.

In step 1065, content manager 503 forwards the true max ID through theremainder of the successor network path back to the SATC or to thetarget database that originally initiated the priority process. Thisstep may be accomplished by sending the true max ID to the successorsystem from which SATC 5000 received the priority-process request priorto step 1000.

Examples and embodiments of the present invention described in thisdocument have been presented for illustrative purposes. They should notbe construed to be exhaustive nor to limit embodiments of the presentinvention to the examples and embodiments described here. Many othermodifications and variations of the present invention that do not departfrom the scope and spirit of these examples and embodiments will beapparent to those possessed of ordinary skill in the art. Theterminology used in this document was chosen to best explain theprinciples underlying these examples and embodiments, in order toillustrate practical applications and technical improvements of thepresent invention over known technologies and products, and to enablereaders of ordinary skill in the art to better understand the examplesand embodiments disclosed here.

What is claimed is:
 1. A disaster-recovery system comprising aprocessor, a memory coupled to the processor, and a computer-readablehardware persistent-storage device coupled to the processor, thepersistent-storage device containing program code configured to be runby the processor via the memory to implement a method for synchronoussite-consolidated data backup with synchronous-to-asynchronous trafficconversion, the method comprising: the processor detecting that atransaction has been performed upon a source database; the processoridentifying a networked backup path, from the source database to atarget database, through which each transaction performed on the sourcedatabase is replicated to the target database, where each node on thebackup path hosts a distinct SATC (Synchronous-to-AsynchronousConverter) module, of a plurality of SATC modules, that stores a copy ofany replicating transaction that passes through the distinct SATC modulewhile traversing the backup path, and the processor creating a set oftracking entries for the detected transaction, where the set of trackingentries identifies each SATC hosted by a node of the backup path andassociates the detected transaction with the source database, with thetarget database, and with each SATC hosted by a node of the backup path;the processor receiving a copy of the detected transaction from apredecessor SATC; the processor confirming that the detected transactionhas been locally stored in a successor SATC hosted by a node thatimmediately follows the predecessor SATC's node along the backup path;and the processor accepting from the successor SATC confirmation thatthe successor SATC has in turn accepted confirmation, from a next SATCalong the backup path, that the next SATC has successfully received thedetected transaction from the successor SATC, and then locally storedthe detected transaction.
 2. The disaster-recovery system of claim 1,further comprising: the processor notifying the predecessor SATC thatthe detected transaction has been successfully stored by both thepredecessor SATC and the successor SATC.
 3. The disaster-recovery systemof claim 2, where each tracking entry of the set of tracking entriesidentifies: the detected transaction, one SATC, hosted by a node of thebackup path, through which a copy of the detected transaction must bereplicated in order for the detected transaction to reach the targetdatabase, and a distinct network node of the backup network that hoststhe one SATC.
 4. The disaster-recovery system of claim 2, furthercomprising: the processor excluding from the set of tracking entries atracking entry that the processor has already included in a previouslycreated set of tracking entries.
 5. The disaster-recovery system ofclaim 2, further comprising: the processor excluding from the set oftracking entries a questionable tracking entry that has not hadsufficient time to be replicated from the source database an SATCidentified by the questionable tracking entry.
 6. The disaster-recoverysystem of claim 5, where the processor excludes the questionabletracking entry because the questionable tracking entry identifies anerroneous transaction of the source database and insufficient time haselapsed for a correction to the erroneous transaction to have beenreplicated from the source database to the SATC identified by thequestionable tracking entry.
 7. The disaster-recovery system of claim 1,where the receiving, the storing, the forwarding, the accepting, and thenotifying are propagated through all SATCs hosted by nodes on the backuppath until the detected transaction has been stored in a localpersistent-storage area of the target database.
 8. A method forsynchronous site-consolidated data backup withsynchronous-to-asynchronous the processor detecting that a transactionhas been performed upon a source database; the processor identifying anetworked backup path, from the source database to a target database,through which each transaction performed on the source database isreplicated to the target database, where each node on the backup pathhosts a distinct SATC (Synchronous-to-Asynchronous Converter) module, ofa plurality of SATC modules, that stores a copy of any replicatingtransaction that passes through the distinct SATC module whiletraversing the backup path, and the processor creating a set of trackingentries for the detected transaction, where the set of tracking entriesidentifies each SATC hosted by a node of the backup path and associatesthe detected transaction with the source database, with the targetdatabase, and with each SATC hosted by a node of the backup path; theprocessor receiving a copy of the detected transaction from apredecessor SATC; the processor confirming that the detected transactionhas been locally stored in a successor SATC hosted by a node thatimmediately follows the predecessor SATC's node along the backup path;and the processor accepting from the successor SATC confirmation thatthe successor SATC has in turn accepted confirmation, from a next SATCalong the backup path, that the next SATC has successfully received thedetected transaction from the successor SATC, and then locally storedthe detected transaction.
 9. The method of claim 8, further comprising:the processor notifying the predecessor SATC that the detectedtransaction has been successfully stored by both the predecessor SATCand the successor SATC.
 10. The method of claim 9, where each trackingentry of the set of tracking entries identifies: the detectedtransaction, one SATC, hosted by a node of the backup path, throughwhich a copy of the detected transaction must be replicated in order forthe detected transaction to reach the target database, and a distinctnetwork node of the backup network that hosts the one SATC.
 11. Themethod of claim 9, further comprising: the processor excluding from theset of tracking entries a tracking entry that the processor has alreadyincluded in a previously created set of tracking entries.
 12. The methodof claim 9, further comprising: the processor excluding from the set oftracking entries a questionable tracking entry that has not hadsufficient time to be replicated from the source database to localpersistent storage of an SATC identified by the questionable trackingentry, where the processor excludes the questionable tracking entrybecause the questionable tracking entry identifies an erroneoustransaction of the source database and insufficient time has elapsed fora correction to the erroneous transaction to have been replicated fromthe source database to the local persistent storage of the SATCidentified by the questionable tracking entry.
 13. The method of claim8, where the receiving, the storing, the forwarding, the accepting, andthe notifying are propagated through all SATCs hosted by nodes on thebackup path until the detected transaction has been stored in a localpersistent-storage area of the target database.
 14. The method of claim8, further comprising providing at least one support service for atleast one of creating, integrating, hosting, maintaining, and deployingcomputer-readable program code in the computer system, wherein thecomputer-readable program code in combination with the computer systemis configured to implement the detecting, the identifying, the creating,the receiving, the confirming, and the accepting.
 15. A computer programproduct, comprising a computer-readable hardware storage device having acomputer-readable program code stored therein, the program codeconfigured to be executed by a disaster-recovery comprising a processor,a memory coupled to the processor, and a computer-readable hardwarestorage device coupled to the processor, the storage device containingprogram code configured to be run by the processor via the memory toimplement a method for synchronous site-consolidated data backup withsynchronous-to-asynchronous traffic conversion, the method comprising:the processor detecting that a transaction has been performed upon asource database; the processor identifying a networked backup path, fromthe source database to a target database, through which each transactionperformed on the source database is replicated to the target database,where each node on the backup path hosts a distinct SATC(Synchronous-to-Asynchronous Converter) module, of a plurality of SATCmodules, that stores a copy of any replicating transaction that passesthrough the distinct SATC module while traversing the backup path, andthe processor creating a set of tracking entries for the detectedtransaction, where the set of tracking entries identifies each SATChosted by a node of the backup path and associates the detectedtransaction with the source database, with the target database, and witheach SATC hosted by a node of the backup path; the processor receiving acopy of the detected transaction from a predecessor SATC; the processorconfirming that the detected transaction has been locally stored in asuccessor SATC hosted by a node that immediately follows the predecessorSATC's node along the backup path; and the processor accepting from thesuccessor SATC confirmation that the successor SATC has in turn acceptedconfirmation, from a next SATC along the backup path, that the next SATChas successfully received the detected transaction from the successorSATC, and then locally stored the detected transaction.
 16. The computerprogram product of claim 15, further comprising: the processor notifyingthe predecessor SATC that the detected transaction has been successfullystored by both the predecessor SATC and the successor SATC.
 17. Thecomputer program product of claim 16, where each tracking entry of theset of tracking entries identifies: the detected transaction, one SATC,hosted by a node of the backup path, through which a copy of thedetected transaction must be replicated in order for the detectedtransaction to reach the target database, and a distinct network node ofthe backup network that hosts the one SATC.
 18. The computer programproduct of claim 16, further comprising: the processor excluding fromthe set of tracking entries a tracking entry that the processor hasalready included in a previously created set of tracking entries. 19.The computer program product of claim 16, further comprising: theprocessor excluding from the set of tracking entries a questionabletracking entry that has not had sufficient time to be replicated fromthe source database to local persistent storage of an SATC identified bythe questionable tracking entry, where the processor excludes thequestionable tracking entry because the questionable tracking entryidentifies an erroneous transaction of the source database andinsufficient time has elapsed for a correction to the erroneoustransaction to have been replicated from the source database to thelocal persistent storage of the SATC identified by the questionabletracking entry.
 20. The computer program product of claim 15, where thereceiving, the storing, the forwarding, the accepting, and the notifyingare propagated through all SATCs hosted by nodes on the backup pathuntil the detected transaction has been stored in a localpersistent-storage area of the target database.